Re: [HACKERS] Daemon News article - Mailing list pgsql-hackers

From Henry B. Hotz
Subject Re: [HACKERS] Daemon News article
Date
Msg-id v04020a06b3761fecd000@[137.78.84.130]
Whole thread Raw
In response to Re: [HACKERS] Daemon News article  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] Daemon News article  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Daemon News article  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At 3:28 PM -0700 5/29/99, Bruce Momjian wrote:
>> The quote from Jolly Chen does not seem consistent with Eric Raymond's

>
>I totally agree that it is inconsistent, but I have never felt Rayond
>was 100% correct.  While I don't believe developers should have a
>'holier than thow' attitude (and I don't think we have), most patches
>from people who did not take the time to figure out how things worked
>were a disaster if applied.  If we don't have reliability, we have
>nothing in the db world, and a bazzar is not reliable.
>

I don't think Eric is claiming that a bazzar is ideal, just that there are
enormous advantages to going ahead and releasing code which isn't quite
done.  Once you have a good framework set up an awful lot of people can
help with the detail debugging.  A really good test case is 90% of a
complete fix.

25 years ago I observed that part of the IBM monopoly was based on how
*bad* their stuff was.  It was so difficult to get things working that by
the time you did you were afraid to do it over with another company.  And
you were kind of proud of the fact that you *did* get it working in the end
after all.

In my opinion, Microsoft has done a similarly masterful job of making
things just good enough that the competition wasn't obviously better, while
making their stuff bad enough to maximize the required custommer
commitment.  This paragraph is intended as a side observation, not flame
bait.

Perhaps the point to make in the paper is just that we have chosen a
particular development cycle/philosophy.  It doesn't happen to coincide
precisely with Eric Raymond's recommendations, but we're not exactly a
cathedral either.

---------------

Responding to what Bruce wrote while I was writing this note:  I don't
entirely agree with the comment about gcc.  Before egcs they generally had
a "stable" release, e.g. 2.5.8, or 2.6.3, or 2.7.2.x that was being widely
used while there was also a "current" release like 2.6.1, or 2.7.1, or
2.8.0.  In their case there was also an internal-only alpha/beta version
which we never saw.  Coming from this background I found it difficult to
evaluate the stability of various Postgres versions because there was no
parallel maintenance of a "stable patched" version independent of the
"development" version.

I still feel it is unfair to expect all developers to "switch gears"
between just fixing bugs and just developing new stuff in order to conform
to a single release cycle.  Some people are better at one than the other.
Likewise I think our users would welcome a choice between a known stable
version and a more featureful current version.  I'm not sure our beta
versions quite provide this kind of distinction.

But at this point I am commenting randomly on actual deveopment policy
rather than on the article.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Daemon News article
Next
From: "Henry B. Hotz"
Date:
Subject: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/storage/bufferbufmgr.c'